This needs one portability fix before merge. The new loop calls labs(num / mult) but num is int64; on platforms where int64 is not long that can truncate or otherwise compare the wrong value for large inputs. The comparison can avoid that by staying in int64 arithmetic, for example by comparing both positive and negative ranges directly rather than calling labs().

The docs also list Z and Y but with the current int64 input those units are not reachable in practice. If the implementation only reaches E, I would keep the documentation to the reachable units.

This is much closer but I think there is still one signed-range issue before merge.

pos_num = num * (num < 0 ? -1 : 1) overflows for INT64_MIN since the minimum signed value cannot be represented as a positive int64. The old code avoided that because it converted to double before negating.

Could the scale-selection loop avoid forming an absolute signed value? For example, compare num / mult against both positive and negative powi thresholds directly, or otherwise handle the minimum signed value without negating it.

Agreed that this is unlikely to be hit in normal use but this helper is specifically in the numeric formatting path and the fix is small enough that I think we should keep it defined for the full int64 range.

There is still one signed-range issue here: assigning to uint64_t does not avoid the overflow because num * -1 is evaluated in signed int64 before conversion. For INT64_MIN, that is still undefined behaviour.

This needs to convert before negating or avoid forming a signed absolute value. For example: uint64_t abs_num = num < 0 ? 0 - (uint64_t)num : (uint64_t)num;

That keeps the INT64_MIN case defined in unsigned arithmetic.

Thank you very much, this looks good to me now. Nice work on cleaning this up and sticking with my tendency for correctness 🤣